Computer information is typically stored in components known as files. A “file,” as used herein, is a complete named collection of information such as a program, a set of data used by a program, or a user created document. Hereinafter, the different types of information that may be within a file are collectively referred to as “file data.” A file may also be thought of as the basic unit of storage that enables a computer to distinguish one set of information from another. Consequently, a file is the “glue” that binds a conglomeration of instructions, numbers, words or images into a coherent unit that a user can retrieve, change, delete, save or send to an output device.
Typically within a particular computer system, all files in that system adhere to a particular format. This format is predefined according to protocols of the file system. A file system is the overall structure in which files are named, stored and organized. A file system consists of files, directories or folders and the information needed to locate and access these items.
In addition to defining the file format, most file systems also provide the framework to allow the creation of file attributes. File attributes are units of information stored in combination with file data to provide information about a file, wherein the attribute information is separate from the actual file data. Generally, most file attributes are standard in nature, including such information as a file name, a file size, a time value, etc. These items may typically be found as part of a header, i.e., a portion of each file that provides information about that file. For example, the file attributes may be automatically updated as the value changes, e.g., the file size or time value may be updated by the system when the file is modified and thereafter saved. Other file attributes, such as the file name may be changed without modifying the contents of the file.
Often, third party applications work in combination with a file system to provide additional system features or functions, such as virus scanning functions. These third party applications may actually “intercept” each file access attempt and scan the file for viruses or perform other tests prior to performing the actual access operation. Unfortunately however, performing a scan operation or other tests each time a file is accessed consumes a significant amount of time. Therefore, a log of information is typically maintained to store version information for each file. For example, the log may maintain a list of files on the system and an indication as to whether each file has been scanned, and if so, which version of virus definition file was used. Using the log of information, the virus scanner can reduce processing time by only scanning files in the file system that are new or modified, or that were scanned by an out-of-date virus definition file.
Although the use of an information log provides a significant improvement over previous systems that scanned every file before each access, using such a log suffers from some drawbacks. For example, maintaining such an information log requires a significant amount of overhead. Moreover, the process of accessing the log to determine whether items have been scanned reduces overall system performance since a separate file must be located on disk and examined. Additionally the log of information is not updated as files are copied or backed up causing unnecessary scanning operations in certain circumstances.
One solution to the performance problems associated with keeping an information log as a separate file has been to keep an “in-memory” log that is created and stored in volatile memory, e.g., RAM. The in-memory log may be accessed more quickly than a separate file, and therefore performance of the system increases when using the in-memory log in place of the log file described above. However, the in-memory log is erased or lost when the power is not delivered to the system, such as when the system is turned off, shut down or rebooted. Thus, any state information or version information may not be determined quickly following a cessation of power. Another drawback associated with the in-memory log is that such a log consumes a significant amount of the operating memory used by the system. Therefore, the in-memory log has not provided an adequate solution to the above-described problems.
It is with respect to these and other considerations that the present invention has been made.